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The Principles of In May 1995 the IPC’s Technical Activities Executive Committee adopted Principles of 


Standardization Standardization as a guiding principle of IPC’s standardization efforts. 
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(DFM) and Design for the Environment (DFE) e Increase time-to-market 
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e Contain simple (simplified) language e Increase cycle time 
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e Focus on end product performance e Contain anything that cannot 
e Include a feedback system on use and be defended with data 


problems for future improvement 


Notice IPC Standards and Publications are designed to serve the public interest through eliminating 
misunderstandings between manufacturers and purchasers, facilitating interchangeability and 
improvement of products, and assisting the purchaser in selecting and obtaining with minimum 
delay the proper product for his particular need. Existence of such Standards and Publications 
shall not in any respect preclude any member or nonmember of IPC from manufacturing or sell- 
ing products not conforming to such Standards and Publication, nor shall the existence of such 
Standards and Publications preclude their voluntary use by those other than IPC members, 
whether the standard is to be used either domestically or internationally. 


Recommended Standards and Publications are adopted by IPC without regard to whether their 
adoption may involve patents on articles, materials, or processes. By such action, IPC does 
not assume any liability to any patent owner, nor do they assume any obligation whatever to 
parties adopting the Recommended Standard or Publication. Users are also wholly responsible 
for protecting themselves against all claims of liabilities for patent infringement. 


IPC Position It is the position of IPC’s Technical Activities Executive Committee (TAEC) that the use and 
Statement on implementation of IPC publications is voluntary and is part of a relationship entered into by 
Specification customer and supplier. When an IPC standard/guideline is updated and a new revision is pub- 
Revision Change lished, it is the opinion of the TAEC that the use of the new revision as part of an existing 
relationship is not automatic unless required by the contract. The TAEC recommends the use 
of the lastest revision. Adopted October 6. 1998 
Why is there Your purchase of this document contributes to the ongoing development of new and updated 
a Charge for industry standards. Standards allow manufacturers, customers, and suppliers to understand one 
this standard? another better. Standards allow manufacturers greater efficiencies when they can set up their 


processes to meet industry standards, allowing them to offer their customers lower costs. 


IPC spends hundreds of thousands of dollars annually to support IPC’s volunteers in the 
standards development process. There are many rounds of drafts sent out for review and 
the committees spend hundreds of hours in review and development. IPC’s staff attends and 
participates in committee activities, typesets and circulates document drafts, and follows all 
necessary procedures to qualify for ANSI approval. 


IPC’s membership dues have been kept low in order to allow as many companies as possible 
to participate. Therefore, the standards revenue is necessary to complement dues revenue. The 
price schedule offers a 50% discount to IPC members. If your company buys IPC standards, 
why not take advantage of this and the many other benefits of IPC membership as well? For 
more information on membership in IPC, please visit www.ipc.org or call 847/597-2872. 
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A standard developed by the Product Data Exchange Task Group (2-15a) 
of the Supply Chain Communication Subcommittee (2-15) of IPC. 


The IPC-2571 standard defines an XML encoding schema that enables a total 
product definition to be described at a level appropriate to facilitate supply chain 
interactions. 


This project was initiated by the NEMI Virtual Factory Information Interchange 
Project (VFIIP) which established proof of concept. After completion, the project 
leaders recommended standardization by IPC under the ANSI rules and 
procedures. 
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Generic Reguirements for Electronics Manufacturing Supply Chain 
Communication - Product Data eXchange (PDX) 


Introduction 


Today, manufacturing is accomplished through the collaboration of a dynamic, global network of original 
eguipment manufacturers, manufacturing service providers, and parts suppliers. To capture market 
opportunities, this network of partners is reguired to function even more efficiently than would a single 
company which kept control of all production processes in house. 


Virtual manufacturing networks, such as these, are highly dependent on accurate and immediate product 
content information. Yet today's manufacturing networks are often forced to rely on inadequate paper- 
based communications like faxes and emails, or on web pages that are not dynamically linked to the 
source of the product content. 


The dilemma is especially acute among organizations trying to bring electronic products to market. It is 
becoming increasingly rare for companies that design products, which have substantial electronics content, 
to manufacture their own products. It is more typical for the bulk of the manufacturing to be subcontracted 
to an Electronics Manufacturing Services (EMS) provider. The Original Equipment Manufacturer (OEM) 
who designs the product will typically only perform the final assembly and packaging but in some cases, 
even this is sub-contracted. The EMS provider may ship the finished product directly to customers. The 
EMS provider in turn will purchase the bulk of the components either directly from the component 
manufacturers or from distributors. 


Increasingly, even the product design process is a collaborative effort. Often the Electronics Manufacturing 
Services provider or component supplier will suggest changes to a product design based on component 
price or availability information that is not available to the Original Equipment Manufacturer. The pressure 
to both reduce costs and improve products translates directly into a much higher frequency of product 
changes throughout a product's lifecycle. Effective and timely communication of these product changes 
across the supply chain is essential in order to avoid potentially costly rework or dead inventory problems. 


PDX is the Product Data eXchange standard for the e-supply chain. Product Data eXchange is a multi-part 
standard, represented by the IPC 2570 series of specifications. The Product Data eXchange 
standardization effort is focused on the problem of communicating product content information between 
Original Equipment Manufacturers, Electronics Manufacturing Services providers and component suppliers. 
The standard is based on XML because this provides a simple yet powerful and flexible way to encode 
structured data into a format that is both human and machine-readable. The Product Data eXchange 
standard provides a way to describe product content (Bill of Materials (BOM), Approved Manufacturer Lists 
(AML), Drawings, etc.), Engineering Change Requests (ECR), Engineering Change Orders (ECO) and 
Deviations in an eXtensible Markup Language (XML) format. This standard will enable dramatic efficiency 
improvements throughout the supply chain since partners will have a way to exchange product content and 
changes in a common language. 


The OEM companies at the top of the supply chain (SC), originate the product structure and feed it to the 
down stream SC partners. Various design for assembly, fabrication, test feedback (DF*) and material 
status, WIP and Quality information will flow back up the SC to the OEM (i.e. 257* standards). In some 
cases OEMs will be feeding data to both internal EMSs and multiple external EMSs and they need 
methods to make sense of this varying feedback. It is assumed that most SC partners will have several 
internal applications that they use to vault and control the product information (PDMs, ERPs, CAMs, CADs, 
etc). 
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Figure 1 Supply Chain Information Exchange 


As the product structure moves through the supply chain, various subsets of the product information will be 
made available to the suppliers and EMSs. Non Disclosure Agreements and security mechanisms are 
needed that allow this data to be shared in a secure and protected way. For example EMSs usually strip 
the PCB (Printed Circuit Board) information out of the full product data package before sending it on to the 
PCB fabricators. They also partition the BOM when they send quote packages to suppliers as part of the 
component procurement process. OEMs typically decide to partition the complete product structure and 
have different assemblies manufactured by several EMS companies. 


To satisfy this mode of SC information exchange, IPC 257X allows all or portions of the product structure to 
be defined and transmitted. In some cases what appears as a “component” to one SC partner, may in fact 
be a complex assembly to another. The applications generating and processing this standard must be able 
to subset and merge the partial definitions into their company’s internal information models. 


Relationships to Other Standards Initiatives 


IPC 2510 - GenCAM 


The GenCAM standard (IPC 2510) describes printed boards and printed board assemblies. GenCAM 
describes a printed board in enough detail to be able to manufacture and assemble a board. The Product 
Data eXchange standard, on the other hand, is intended for high-level supply chain communication of 
product definition data. Product Data eXchange allows a company to describe a complete system or sub- 
system including hardware and other higher-level assemblies that would not normally be described by 
GenCAM documents. Product Data eXchange does not however define a standard for describing parts and 
assemblies in enough detail to be able to manufacture them. This is achieved only by including other 
documents in a Product Data eXchange package. These other documents may include GenCAM 
documents. There is some overlap in scope between the bill of materials section of Product Data eXchange 
and the parts list section of GenCAM, however there are also significant differences. In a GenCAM file, the 
electrical characteristics of each device are described, as is the placement on the board of each instance of 
that device. A Product Data eXchange bill of material for a printed board assembly can be characterised as 


N 
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a summary of a GenCAM parts list in the sense that it does not contain electrical characteristics or 
placement information. It may however also contain some information such as find numbers or information 
about mechanical fasteners, which is typically omitted from a GenCAM file. In general it should be possible 
for software to generate most of a Product Data eXchange bill of material from a GenCAM parts list but the 
reverse will not in general be possible. There are also some differences in the relative importance of some 
of the optional data that may be included both in a GenCAM parts list and a Product Data eXchange bill of 
material. Notably, both GenCAM and Product Data eXchange allow manufacturer part numbers to be 
recorded. This information may in some cases be omitted from a GenCAM parts list because the choice of 
which of the many possible manufacturer parts to use may not have been made at the time that the 
GenCAM file was generated. In a Product Data eXchange document this information will normally be 
reguired. Engineering Notes, examples, and other engineering related information that is used in a 
GenCAM file through the reference of attachments and utilizing workflow can be transmitted via the 
IPC2571 & IPC2578 series. 


RosettaNet 


RosettaNet is dedicated to the development and deployment of standard electronic business interfaces to 
align the processes between supply chain partners on a global basis. In order to efficiently conduct 
eBusiness, companies require a robust technical dictionary and data structures, a framework for passing 
messages, and conventions for business transactions. RosettaNet addresses these needs by building a 
master dictionary to define properties for products, partners, and business transactions. This master 
dictionary, coupled with an established implementation framework (exchange protocols), is used to support 
the eBusiness dialog known as the Partner Interface Process or PIP. 


RosettaNet has well-defined Partner Interface Processes for the exchange of data about complete products 
and data about electronic components, and is embarking on developing a mechanism for exchanging 
manufacturing information. Product Data eXchange provides exactly this missing capability. It is 
anticipated that the data descriptions in Product Data eXchange will be leveraged into RosettaNet Partner 
Interface Processes to provide an end-to-end solution for the entire electronics supply chain. 


Open Applications Group, Incorporated (OAGI) 


The Open Applications Group, Incorporated has defined standard interfaces between enterprise software 
applications. The scope of the Open Applications Group, Incorporated Interchange Specification (OAGIS) 
overlaps to a small extent with the Product Data eXchange standard, and it is anticipated there will be 
opportunities for consolidation in the future. 
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Figure 2 Multi-level Product BOM Structure 
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1 Scope 


The Product Data eXchange 1.0 standard defines an XML encoding scheme that enables a total product 
definition to be described at a level appropriate to facilitate supply chain interactions. The scheme is 
defined for bill of materials (BOM), approved manufacturer list (AML), changes (Engineering, 
Manufacturing, Product) and references to documents describing geometric and other definition 
characteristics. 


IPC 2571 is the umbrella specification for other IPC 2570-series specifications. It describes the Package 
element that is required for every Product Data eXchange implementation, as well as other common 
elements shared across the 2570 series. The sectional standards provide application exchange capability. 
IPC 2576, for instance, transfers as-built product configuration data, and IPC 2578 defines specific product 
definition elements such as items, changes, bills of material (BOMs), and approved manufacturing lists 
(AMLs). 


The IPC 2570-series of standards transfer the data required to support the following business processes: 


e Quote request 

e Manufacturing 

e Engineering change management (including signoff) 
e Work in Process (not started) 

e Report on Quality (in development) 


e Report on as-built product configuration 


2 Applicable Documents 


The following documents are related to the Product Data eXchange efforts. 


2.1 IPC Documents 


The following documents contain provisions, which, through reference in this text, constitute provisions of 
this standard. All documents are subject to revision. Parties who make agreements based on this standard 
are encouraged to investigate the possibility of applying the most recent editions of the documents 
indicated below. 


IPC-T-50 Terms and Definitions for Interconnecting and Packaging Electronic Circuits. 

IPC 2510 Generic Computer Aided Manufacturing Descriptions for Printed Boards and Printed Board 
Assembly. 

IPC 2576 Product Data eXchange — Sectional Requirements for Electronics Manufacturing Supply 


Chain Communication of As-Built Product Data 


IPC 2577 Product Data eXchange — Sectional Requirements for Supply Chain Communication of 
Manufacturing Quality Assessment 


IPC 2578 Product Data eXchange — Sectional Requirements for Supply Chain Communication of Bill 
of Material and Product Design Configuration Data 
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2.2 RosettaNet Documents 


The following are RosettaNet Partner Interface Process documents that relate to this standard, and reflect 
an effort made by both organizations towards harmonization. 


RosettaNet PIPs 2C1-10 (IPC2578) Product Design Information 
Segment 7A Design Transfer 
Segment 7C Distribute Manufacturing Information 


2.3 OAG Documents 


OAGIS Open Applications Group Interchange Specifications will be used to harmonize with this 
standard and will be incorporated in later revisions of this standard. 


2.4 RFC Documents 
RFC 1950 ZLIV Compressed Data format Specification 3.0 


RFC 1951 DFLATE Compressed Data Format Specification Version 1.3 
RFC 1952 GZIP file format specification 4.3 


3 Product Data eXchange Package 


This standard uses a single XML file in the format described by this specification to represent a Product 
Data eXchange (PDX) package. The Product Data eXchange package can reference external attachments 
(see attachments section below). The XML file will be named “pdx.xml". The pdx.xml file must contain a 
single ProductDataeXchangePackage element and optionally the other elements described in this 
specification. The pdx.xml file may also contain elements from the other IPC 257x PDX standards. 


Since a Product Data eXchange package can be one XML file and an unlimited number of external 
attachments, one way to communicate the Product Data eXchange package as a single package is to 
compress the files as described in Internet RFC's 1950 through 1952.. This not only brings all the files 
together in one file for ease of delivery, but also compresses the files to reduce their size. Compression is 
particularly useful for XML files since they tend to be very large with large amounts of repeated data and 
thus compress significantly. This compressed file consisting of the pdx.xml file and any external 
attachments can be named a Product Data eXchange file with a “.pdx” extension and the MIME type can 
be application/x-pdx. The compression of the Product Data eXchange package contents is optional and is 
not required by this specification. The sending and receiving partners must define this as part of the 
transport layer they use for communicating Product Data eXchange packages. 


The Product Data eXchange package requires internal Document Type Definition (DTD) file inclusion so 
the entire content of the DTD file is included in the pdx.xml file. The DTD is included at the end of this 
document. In addition to the mandatory XML process instruction of <?xml version = "1.0"?>, or <?xml 
version = "1.0" encoding="UTF-8"?>, the pdx.xml file also includes two other process instructions: 
<?pdx version = “1.0"?>, which states in which version of Product Data eXchange standard the package is 
formed, and <?generated by SoftwareVendor/SoftwareName/Version/BuildNumber?>, which states which 
version of what software was used to create the package. 
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3.1 Modeling Diagram Occurrence Indicator Meanings 


Occurrence indicators are used within element content models to specify how many times an element may 
appear at a given location. The indicators available to schema developers are listed below: 


Occurrence Meaning 
Indicator 
none The element must appear once and only once. 
? The element (or group of elements) may appear zero or one times. 


The element is optional, but is only allowed to appear once. 


+ The element (or group of elements) must appear one or more times. 
The element is reguired to appear at least once, but multiple 
consecutive occurrences may be present. 


ki The element (or group of elements) may appear zero or more times. 
The element can appear as many times consecutively as needed, or 
even zero times. 


Note that graphics and a table of attribute descriptions are provided as an aid to understanding the 
elements in the PDX standard suite. In any instance where the XML DTD conflicts with an image or 
description, the DTD should be considered normative. 


IPC-2571 November, 2001 


4 Pictorial Representation of IPC2570 Series 


The following illustrations provide a graphical representation of some of the primary elements contained in 
the suite of Product Data eXchange standards: 


4.1 Product Data eXchange Package 


-thisDocumentidentifier, -thisDocumentGenerationDateTime_ -thisDocumentModificationDateTime_ 2) orlginatedByContactName, 
string dateTime dateTime string 
-originatedByContactUniqueldentifier, «packageType, „description -dataSource. 

2 5 © t © 1 © N 

idref string string string 

-thisDocumentCopyright, 

? d 

string 


+ AdditionalAttributes, 
«ltems, 


27 Changes_ 


3 ManufacturerParts_ 


*ProductDataeXchangePackage_ «SupplierParts, 


EN 
2 \ History, 


3) Attachments, 


> Contacts, 


zr AsBuiltProduct, 


4.2 Items 


‘items, lem 
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-itemidentifier, itemUniqueldentifier, > -globalLifeCyclePhaseCode, 9) 9lobalLifeCyclePhaseCodeOther, 
string lid 3 enumeration Istring 
„rglobalProductTypeCode, , |:itemClassification, >)‘ revisionidentifier, G- Versionidentifer, 
string j string string | string 
| proprietaryProductFamily J py category, i ‘globalProductUnitofMeasurecode, (7 makeBuy, 
string | istring J string ‘enumeration | 
(>) makeBuyoOther, (| minimum ShippableRevision, (>) revisionReleasedDate, (zl revisionincorporatedDate, 
~ string | string "dateTime "dateTime j 
(z isSerializationRequired] >,“ isCertificationRequired, ` —ownerame, b a aca 
~ enumeration J “enumeration “string j lidref 
G jp sToplierst) G description, 
~ enumeration | istring 
(p| AdditionalAttributes, 
Ei BillOfMaterial, 
5 pero kame i ner 
S) ssa 
L 
H Attachments ‘ 
"lem. | 
dll g renner, 
5 | Characteristics, 
5 “Alternateltems, 
G | SerialNumbers, 
a al 
4.3 Additional Attributes (see 10.1) 
*groupLabel, 
string | 
«name, Been, qe (>) dataType : 
fasa tý (r AdditionalAttribute.. string ) string string ~ Cfenumeration 
1 7 a o 1 description, 
"string i string j 
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44 Changes 


. SES @ Change 


«changeNumber,  — —revislonldentter, > «changeOriginatedByName, 5, -changeOriginatedByContactUniqueldentifier_ 


string "string "string idref 
|-globalEngineeringChangeStatusCode| > globalEngineeringChangeStatusCodeOther, |-changeStatusDate | >, changeType, 
enumeration string dateTime string 
3 changeSubType > ¡changeOriginationDate, > «requestReason, > *changeReason, 
"string $ dateTime "string "string 
— workflow)  5|:changeRequestDescription] 5|-changeOwnerName] 5 |-changeOwnerContactUniqueldentifier, 
"string "string "string ~ idref 
>/ description, 
string 


+ AdditionalAttributes | 
9) History, 

«Change, | — Attachments, 
2 „Approvers, 


¿5 Affectedltems, 


4.5 Manufacturer Parts 


*ManufacturerParts, ç ast 


«manufacturerPartidentifier, >, manufacturerPartUnigueldentifier, «manufacturerName, >, manufacturerContactUniqueldentifier, 
string id string idref 
„rglobalManufacturerPartStatusCode, > „globalManufacturerPartStatusCodeOther, 2 „referenceNotes, > ¡'manufacturerPartType, 
enumeration string string string 
2 description, "owner, "ownerContactUniqueldentifier, > isTopLevel, 
string "string "idref "enumeration 


„| AdditionalAttributes, 


2 „ApprovedSuppiierList, 


-ManufacturerPart, (History, 


2 


2 Attachments, 


> „Alternateldentifiers 


10 
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4.6 Supplier Parts 


"SupplierParts. 7 |: SupplierPart 
W 
+ supplierPartldentifier, 2 y supplierPartUniqueldentifier, +supplierName, >)’ SupplierContactUniqueldentifier, 
string id string idref 
2] globalSupplierPartStatusCode, >| "eferenceNotes, >) SupplierPartType, >] ownerName, 
string string string string 
>| ownerContactUnigueldentifier. (> «isTopLevel, > «description, > -globalReturnProductinstructionCode, 
~ idref “ enumeration "string "string 
+ AdditionalAttributes 
+" SupplierPart, >) History, 
>) Attachments 
4.1 History (see 7.1) 
. deeg, E | Historyltem 
A 
‘action, > *revisionidentifier, ‘userName, 5 EE 
string S (string j string |“ lidref 
«modificationDate, /3|-historyltemStatus, C bag, CC beaiéingier 
dateTime [string string [string 
* Historyltem i G *AdditionalAttributes | 
4.8 Attachments (see 8.1) 
Acne e beier, 
aj referenceName, -universalResourceldentifier] > Bierger | versionidentifer, 
string ; URI | string "string 
qa C edad «isFileln | aio 
“integer — [string enumeration ` "string 
3, globalMimeTypeGualifierCode, (> attachmentModificationDate 
= [string | IdateTime 


«Attachment, — | AdditionalAttributes, 
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4.9 Contact (see 9.1) 


‘Contacts|, ç EE 
-contactidentifier, -contactUniqueldentifier_ «contactName, >, addressLine1, 
string id string string 
q addressLine2, />):addressLine3, >| -citYName, —2)-regionName, 
string string string string 


> globalCountryCode, —„/nationalPostalCode, — >,telephoneNumber, 7) facsimileNumber, 
"string "string "string string 


> department, 2: businessName, „| -globalBusinessldentifier, „remailAddress, 


2 string Gen Z string 2 string 

>, universalResourceldentifier, 2 ¡contactStatus,  “isTopLevel, ` — “globalPartnerClassificationCode, 

“URI string ~ enumeration ~ enumeration 

>, 9lobalPartnerClassificationCodeOther, «globalPartnerSubClassificationCode, > ¡“globalLocationidentifier, ——|-postOfficeBoxidentifier, 
"string " string string "string 


zr AdditionalAttributes, 


27 History, 


“Contact, «Attachments, 


2! 


+ ContactRoles, 


+ y PublicDigitalCertificate 


4.10 AsBuilt Product 


«globalProductidentifier, «asBuiltProductQuantity, | manufacturerUnitOfMeasure, > customerProductNumber, 


2 


string float "string "string 
2 ¿ customeridentifier, >) primaryldentifier, > ¡«secondaryldentifier | «isTopLevel, 
string string string enumeration 


+ y Productinstance, 
-AsBuiltProduct, 
¡+ AdditionalAttributes, 
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4.11 Product Instance 


-itemUniqueldentifier_ | proprietaryProductFamily, > 9lobalBusinessldentifier, 


-itemidentifier, 2) 

string idref string string 
> |-globalProductidentifier, > [traceabilityType| >, manufacturerName, — > [-productRevision, 
"string "string "string "string 
>, ProductVersion, *«buildDate, *«materialldentifier, 7 *forecastProductidentifer, 

"string dateTime ` string ` "string 

3, purchaseOrder, (> purchaseOrderLineltem, ,-authorizationLineltem, >|: customerSerial, 
"string "string "string "string 

>, customerPart, > customerRevision, „seguenceNumber, ¡"manufacturingPartStatus, 
"string string integer string 

„rcustomerVersion, „rglobalLocationldentifier, „rglobalCountryCode, ¡«description, 

string string string string 

CN proprietarySerialldentifier, 

"string 


z, AdditionalAttributes, 

5 „Configuration. 

+ Lot. 
*Productinstance_ 


z WorkOrder. 


+ Packaging. 


a Process! 
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5 Recommended Implementation Practices 


5.1 Inclusion of Linked Objects 


In order to fully understand ID and IDREF, please refer to the XML W3C standard. These are values that 
are unique to the individual PDX package. You may view them as virtual flat file pointers. ID and IDREF 
have no value outside of the PDX package. 


Objects are often linked to other objects by referring to them. For example, the 
manufacturerContactUnigueldentifier refers to a contactUnigueldentifier by use of IDREF and ID 
respectfully. The attributes used to link objects are of type IDREF and are defined in the Product Data 
eXchange diagram. The ID field is not optional and must always be populated to define the ID of the 
referred object. Every IDREF must have a corresponding ID entry. 


Contact information exchanged within this standard is different than the contact information found in 
RosettaNet headers in that the information concerns a role of engineering manager, purchasing manager, 
test engineer, etc. and not to the IT contact person that is referenced in RosettaNet headers for the 
purpose of delivery and receipt of transactions. This technigue can also be used to send an entire contact 
list with referential information on all contacts between trading partners in bulk and then agreeing upon 
referential cross identification of roles and responsibilities and any reguired or optional approval or alternate 
approval contact information. The reguirements of approvaľs and tracking is in the workflow layer and 
therefore beyond the scope of this standard and should be addressed in either a transport standard such 
as RosettaNet or OAG, or in the implementation workflow by the solution provider, or by the trading 
partners through mutual agreement of management of the information exchanged in the workflow layer in 
implementing the IPC257x standard. However, there are available optional attributes that assist the 
workflow layer. 


5.2 Attachments 


The Product Data eXchange package may include attachments that are necessary as part of the product 
content. These may be any kind of file including a Universal Resource Identifier (URI) reference, other 
XML/DTD documents, corresponding XSL files, drawings, Gerber files, test specifications, etc. Attachments 
may be handled in the following ways: 


e Included in the package — The attachment is included as part of the Product Data eXchange package 
and is delivered with the package. The “isFileln" attribute is set to “yes” to indicate that the product data 
includes an attachment referenced via a URI. This requires careful communication as the contents of a 
URI are not managed as part of the package and can change independently. The “isFileln" attribute is 
set to “no” to indicate that the product data references an attachment, but the attachment is not 
included as part of the package. 


e Referenced via FileName — The metadata, including the FileName that is associated with the 
attachment is included, but the attachment itself is not included. The “isFileln” attribute is set to “no” to 
indicate that the product data includes an attachment, but the attachment is not included as part of the 
PDX package. One use of this feature is when the sender knows the recipient already has the 
attachment and does not wish to resend it. 


e Excluded from the package — The attachment can be excluded from the package entirely by giving no 
reference to the attachment in the package. 
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5.3 Missing Reguired Attributes 


If the data source used to generate a Product Data eXchange package does not have a value for a 
required attribute, the value of the attribute should be set to "" so that the package won't be rejected by an 
application using a validating XML parser. 


It is recommended that workflow rules be established such that error level checking is enabled for various 
levels, such as: critical, required, suggested, split, optional, obsolete, isolate — do not use category. The 
resulting communication should be one of logging, alerts, escalation, tracking and resolution. It is 
encouraged that the use of roles within the contact element should be defined between partners in 
facilitating this communication within the workflow layer but is beyond the scope of this standard. 


5.4 Avoid Data Duplication in Product Data eXchange Package 


If a Product Data eXchange package has two objects that share a sub-assembly or an item, the shared 
data (both meta data and possible attachment files associated with them) should not be duplicated in the 
package. For example, in figure 3, object A and P share the sub-assembly C. When a Product Data 
eXchange package contains both object A and P, the data of the C assembly should be included in the 
package only once. It must be noted that any change in any underlying part or assembly requires a 
change in the levels above so as to keep each level unique for clarification in manufacturing. It may, 
however, be agreed within the supply chain trading partners the level above is not materially affected from 
a business or engineering reason and therefore may not need to be changed. However, this is 
discouraged in use so that a complete audit trail for warranty entitlement can be maintained. 


Figure 3 Assembly Hierarchy 


This consideration led to the important design decision to define Item in a flat structure instead of an 
embedded or recursive structure. Doing so makes it possible to include just one instance for multiple 
presences of a given object in a PDX package; the instance would then be referenced in multiple places. 


The avoidance of data duplication is a recommended practice, which the Product Data eXchange standard 
does not enforce, and transmitting data duplication in a Product Data eXchange package does not 
constitute a violation of the standard. There are standard practices within government or industry groups 
that require a complete “line by line” transmittal of information, which would require data duplication in 
lower subsections of the BOM. Therefore, the standard does not prohibit the practice of sending a fully 
duplicated subsection of the BOM for adherence to established practices. 
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It should be noted that the package could be used to transmit complete contact information without other 
information. The same is true of a complete BOM with partial buyer required elements for RFQ submittals. 
AML vendors database information can be transmitted in bulk form also. This allows the loading of 
catalogue information in bulk for components and their suppliers. It is up to the particular application to 
make use of cross-reference information capabilities that are available in IPC257x series. The 
AdditionalAttributes element can be used to transmit additional purchasing information including pricing 
which is beyond the scope of this standard but allows this standard to be used in RFQ and Quote 
Response scenarios. 


By sending bulk load information separate, only updated or changed — delta — information need to be 
transmitted unless an error is encountered. 


5.5 Excluding data from the Product Data eXchange package 


The Product Data eXchange standard supports the ability to send incremental change data or subsections 
of the element tree, rather then replicate data supporting an entire BOM with every Product Data eXchange 
package sent. 


For example, when an ECO is sent for a particular product, it is unnecessary to send the entire Product 
Data eXchange file to the agency responsible for implementing the ECO if it is known that the agency has 
the data loaded into their system. It would only be necessary to send the changes to the Product Data 
eXchange document. 


If data is excluded from a Product Data eXchange package, the sender should verify that the pruned 
Product Data eXchange package can stand-alone and be understood by the recipient. For example, BOM 
subsets/subtrees, BOM mark-ups, or AML mark-ups may be sent without all related data included. The 
sender should ensure that the Product Data eXchange package contains enough information to identify the 
change being communicated and its association with all other effected elements. 


In particular, BOM changes, AML changes, schematic changes (attachments), and other attachments 
should all be linked and identified with each other, and be tagged with ECO identification specified by the 
Product Data eXchange standard. Sub-assemblies within a BOM should be able to be transmitted to 
recipients without needing to send the entire BOM. For example, a product sub-assembly is to be 
contracted to a particular Electronics Manufacturing Services provider, which doesn’t need the entire BOM. 
The Electronics Manufacturing Services provider may be involved in manufacturing several subtrees of the 
BOM at various levels, and the standard can be used to transmit the appropriate BOM subtrees without 
needing to transmit the entire BOM, for a more efficient transmission. This is particularly needed when the 
Product Data eXchange goes back and forth due to negotiation between the originator of the design and 
the manufacturer of some of the sub-assemblies. Any process that is lengthy and unwieldy will result in an 
impediment to the process of converging on an agreed upon solution. 


However, best practices should require a fresh resend of the complete BOM subsection or other subsection 
information upon error in processing an incremental change with alert notification of all trading partners 
involved. A more sophisticated and elegant solution would be to have systems resend and compare 
information higher up in the BOM tree structure or other tree structure until successful synchronization of 
the database occurs without the need of human intervention or escalation unless directed in the workflow 
layer. It is not a violation of this standard for a complete database or subsection database “refresh” to be 
transacted on each change or at predetermined intervals if the trading partners so agree. The PDX 
standard provides content definition. The implementation of the workflow process is beyond the scope of 
this standard and is left to other standard bodies, implementers and solution providers, which deal 
specifically with the workflow layer of implementation. 
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5.6 Format of DateľTime Fields 


The recommended format for date/time data is a string containing W3C datetime format of the current date 


and time. (See http://www.w3.org/TR/NOTE-datetime-970915.html). The following formats from the W3C 


specification are allowed: 
Complete date: YYYY-MM-DD (eg 1997-07-16) 
Complete date plus hours and minutes: YYYY-MM-DDThh:mm TZD (eg :1997-07-16T19:20+01:00) 


Complete date plus hours, minutes, and seconds: YYYY-MM-DDThh:mm:ssTZD 
(eg: 1997-07-16T19:20:30+01:00) 


Complete date plus hours, minutes, seconds and a decimal fraction of a Second 
YYYY-MM-DDThh:mm:ss.sTZD(e.g. 1997-07-16T19:20:30.45+01:00) 


Where: 
YYYY = four-digit year 
MM _ = two-digit month (01=January, etc.) 
DD = two-digit day of month (01 through 31) 
hh = two digits of hour (00 through 23) (am/pm NOT allowed) 
mm = two digits of minute (00 through 59) 
ss = two digits of second (00 through 59) 
s =oneor more digits representing a decimal fraction of a second 
TZD = time zone designator (Z or +hh:mm or -hh:mm) 


Since all the attributes in Product Data eXchange are defined as character strings due to constraints of 
XML DTD, the above recommended date/time formats cannot be enforced by the current version of the 
Product Data eXchange standard. It is up to Product Data eXchange package generating applications to 
voluntarily adhere to these recommendations. In suggested best practices, the diagrams illustrate strong 
data typing associated with Schema Development as do the included tables. 


5.7 isTopLevel Attribute 


The isTopLevel attribute is used to indicate how an object (of type item, ManufacturerPart, or SupplierPart) 
fits into a Product Data eXchange package. The isTopLevel attribute provides Product Data eXchange 
parsers an efficient mechanism to identify the top-level item of an assembly. 
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6 ProductDataeXchangePackage 


The ProductDataeXchangePackage element is required for every Product Data eXchange file. It is the root 
element of a Product Data eXchange transmission and describes the package as well as all the data within 
the package. There can be only one ProductDataeXchangePackage element in each 
ProductDataeXchange package. 


«thisDocumentidentifier, -thisDocumentGenerationDateTime_ -thisDocumentModificationDateTime_ +originatedByContactName, 


string dateTime dateTime ? string 
> originatedByContactUnigueldentifier, 2 «packageType, description, > «dataSource, 


" idref string "string string 


7 thisDocumentCopyright, 
"string 


z rAdditionalAttributes 
Items, 

-Changes_ 
*ManufacturerParts 
«ProductDataeXchangePackage +SupplierParts, 
«History, 
-Attachments, 


«Contacts 


zr AsBuiltProduct, 


thisDocumentldentifier CDATA | #REOUIRED ID for a package. It is recommended that it is universally 
unique. There is no format defined for it. Any algorithm 
generating such an id can be used. 

thisDocumentGenerationDateTime CDATA | #REQUIRED The date and time when the package was generated. Refer 
to section 5.6 for suggested formats. 

thisDocumentModificationDateTime CDATA | #REQUIRED Date and time when the package was last modified. Refer to 
section 5.6 for suggested formats. 


originatedByContactName CDATA | #IMPLIED Originator | Originator of the package 00000000000] the | Originator of the package 00000000000] 
originatedByContactUniqueldentifier IDREF #IMPLIED Originators contact element 


packageType CDATA | #IMPLIED Type of package. It is recommended values: Manufacture | 
ChangeReguest | ChangeOrder | ChangeNotification | Test | 
Kit | BuildReport 
CDATA | #IMPLIED Description of the package 


CDATA | #IMPLIED Source of the package 
thisDocumentCopyright CDATA | #IMPLIED Copyright information of the package 
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7 History 


The history element holds a collection of Historyltem elements that together describe the entire history of 
the related object. 


7.1 Historyltem 


«History! , Sy Historyltem, 


-action| 3! revisionidentifier | -userName, 5\"userContactUniqueldentifier, 
string string sting J lidref J 
modificationDate) — (3) historyltemStatus, />y'details, (>j comments, 

dateTime string Ň string ` "string 


*Historyltem, | + AdditionalAttributes, 


The Historyltem element describes a specific historic action. 


CDATA #REOUIRED Date and time of the action 
CDATA #IMPLIED Status of the object 
CDATA #IMPLIED Specific details related to the action taken. 


CDATA #IMPLIED Free-form comments for this event. These are general 
comments on the action. 
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8 Attachments 


The attachments element contains all the attachment elements associated with a specific object. 


8.1 Attachment 


The attachment element is a pointer to a file either through a URL or within the Product Data eXchange zip 
file. If the file is zipped and included in the Product Data eXchange package, the FileName contains the 
name of the file. Otherwise, the full URL of the file location is contained in the FileName. There is one 
attachment element for each attachment associated with an object. 


*Attachments, ¿1 Attachment, 


„referenceName, «universalResourceldentifier, — /2)-fileldentifier,, |versionldentifer, 


V We e, ZA. 
string URI string (string 

>| fileSize, (> checkSum, «isFileln | > (description. 

~ linteger "string o enumeration string 


>| globalMimeTypeQualifierCode, — 3): attachmentModificationDate, 
"string "dateTime 


Attachment a + AdditionalAttributes | 


referenceName CDATA #IMPLIED User specified file name (eg: file.doc) 


universalResourceldentifier #REQUIRED A network-centric identifier that provides the fully 
attributed identity of a resource. Refer to IETF RFC 
2396 for further definition. If referring to a file contained 
in the PDX package, use the file://filename notation. 


fileldentifier #IMPLIED Unique identifier for the file; may be a key to the file. 
This field may be used when several attached files have 
the same filename. 


versionidentifier CDATA #IMPLIED Version of the file 


checkSum CDATA #IMPLIED MD5 message digest algorithm, RFC 1321 
(FTP://NIS.NSF.NET/internet/documents/rfc) 

isFileln Yes | No #REQUIRED Flag to indicate if file is included in Product Data 
eXchange package. 


description CDATA #IMPLIED File description 


globalMimeTypeOualiferCode CDATA #IMPLIED The MIME type. Refer to http://www.iana.org for a list of 
types. 


attachmentModificationDate CDATA #IMPLIED Datetime stamp of file 
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9 Contacts 


The contacts element is used to hold a collection of contact elements. 


9.1 Contact 


Each contact represents an individual or entity. The main differentiating factor between the RosettaNet 
RNIF 1.x or 2.0 contact field and the PDX element is that the contact information within this standard 
assigns additional roles (beyond information technology). For example, trading partners that wish to effect 
a Engineering Change Order (ECO) have different persons within their company who are responsible for 
reviewing the ECO and agreeing to implementation or “cut in" date, and reviewing the proposed changes 
as it may effect purchasing, test engineering, production, etc. Therefore, a contact may have the role of 
Engineering Manager whose digital signature is determined to be required for approval of the ECO. 


Although the workflow of ECO“ is beyond the scope of this standard, it is anticipated that implementers will 
use the role information in order to track the approval process. The Engineering Manager, in the example 
above, may have alternate people who can “signoff" on the approval in his/her absence. In such an 
instance, the isAlternate attribute of the GroupRole entity would be set to “yes” for the role of Engineering 
Manager. A person can occupy more than one role. Furthering the example, the Test Engineering 
Manager may have “veto” power on an EC through his/her role as Test Engineering Manager but is not 
required to sign. The Engineering Test Manager could also be the alternate signoff designee for the 
Engineering Manager role that has a requirement for approval before an ECO can be implemented. 


The PublicDigitalCertificate (optional) can have multiple entries that can be used in the “signoff” process. 
Multiple digital certificates are available due to a person possibly using two or more different certificates, 
one from each trading partner involved. 
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*Contacts | pr Contact, 
-contactidentifier | -contactUniqueldentifier_ «contactName, ` —.— address ner, 
string id A string "string 
>| addressLine2, )-addressLine3, 7 “cityName, (> regionName, 
"string "string "string "string 
>, globalCountryCode, — ,2)-nationalPostalCode, /2)-telephoneNumber, ,|-facsimileNumber, 
"string "string "string "string 
> department, (> businessName, > *globalBusinessldentifier, > -emailAddress, 
"string "string "string "string 
> UniversalResourceldentifier, >)-contactStatus| «isTopLevel, (3) globalPartnerClassificationCode, 
“URI "string enumeration "string 
>) globalLocationldentifier, >): postOfficeBoxldentifier, 
"string "string 
+ y AdditionalAttributes, 
>) History, 
«Contact, >) Attachments, 


„v ContactRoles, 


z, PublicDigitalCertificate | 


Attribute Name 


contactldentifier 


contactUnigueldentifier 


contactName 


addressLine1 
addressLine2 
addressLine3 
cityName 


regionName 


globalCountryCode 


nationalPostalCode 


telephoneNumber 


facsimileNumber 


department 


businessName 


globalBusinessldentifier 


Im #REOUIRED Unigue Pointer for referencing this contact 


Name of the contact person(s) within the 
organization 

The first line of a physical address 

The second line of a physical address 

The third line of a physical address 


CDATA #IMPLIED The name of a province or state within a 
country 


CDATA #IMPLIED Code identifying geographic location as 
specified by a national postal code 

CDATA #IMPLIED The numeric schema designed to achieve 
contact via telephone 

CDATA #IMPLIED The numeric schema design to achieve 
contact via facsimile 


CDATA #IMPLIED Department or Mail Stop 
CDATA #IMPLIED The name of a business entity 
CDATA #IMPLIED A unique business identifier (DUNS). 


CDATA #IMPLIED Code identifying the two character country 
code specified in ISO 3166-1993 
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universalResourceldentifier | CDATA #IMPLIED Company s URI 


contactStatus CDATA #IMPLIED 
isTopLevel (Yes | No) #IMPLIED 


globalPartnerClassification | (Carrier | #IMPLIED 
Code Distributor | 
EndUser | 
EndUserGovernment | Financier | 
Manufacturer | 
Retailer | 
Shopper | FreightForwarder | 
Broker | CustomsBroker | 
Warehouser | DistributionCenter | 
ContractManufacturer | 
Reseller | 
OriginalEquipmentManufacturer | 
Other) 


globalPartnerClassification | CDATA #IMPLIED 
CodeOther 


globalPartnerSubClassifica | CDATA #IMPLIED 
tionCode 
globalLocationldentifier CDATA #IMPLIED 


CDATA #IMPLIED 


postOfficeBoxldentifier 
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Status — suggest use “active”, “alternate”, 
“inactive”, etc. 


Set to yes if the contact is at the top level of 
the PDX package. Set to no if the contact is 
an element of another object. (Default is No) 


Code identifying a partner’s function in the 
supply chain. Default is Unspecified 


If the above globalPartnerClassificationCode 
attribute is set to “Other”, use this attribute to 
provide a more descriptive value. If the 
above globalPartnerClassificationCode is 
NOT set to “Other”, LEAVE THIS FIELD 
BLANK. 


Code further identifying a partner’s function 
in the supply chain. 

Location uniquely identified by the DUNS +4 
number. 


The proprietary identity of a physical 
address, located at a post office, designed 
solely to accept or receive mail. 


IPC-2571 November, 2001 


9.2 ContactRoles 


ContactRoles allow an implementer of this standard to assign multiple roles to indviduals. The groupLabel 
attribute could contain the project name, division, or other designator. The groupLabel is coupled with zero 
or more ContactRole attributes. The groupRoleDescription may contain descriptions such as Engineering, 
Purchasing or other descriptions which may be applicable between the trading partners. The isAlternate 
element allows for others being able to “signoff” within the approval process. 


*groupLabel, 
string 


*ContactRoles | + ContactRole | 


groupLabel CDATA #REQUIRED Label for the grouping of roles 


9.2.1 ContactRole 


>) groupRoleDescription, 
"string 


+ContactRole | re GroupRole | 


groupRoleDescription CDATA #IMPLIED Optional description or may be used to further subdivide 
grouping classifications 


9.2.2 GroupRole 


*GroupRole | «role, «isAlternate, />)- description, 
string enumeration "string | 


[roe CDATA #REQUIRED Agreed upon role classification between trading partners 


E (Yes | No ) #REOUIRED Represents whether this contact is an alternate 
approval/disapproval role. For the primary role 
responsibility, this value should be set to No. 


| description | CDATA #IMPLIED Description of the role 
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9.3 PublicDigitalCertificate 


A digital certificate may be used to encrypt an attachment, for non-repudiation of approval/disapproval, and 
allows embedding of security within the PDX package exchange. 


-PublicDigitalCertificate | ‘ publicDigitalCertificate, > |-trustedRoot, > trustedRootURI| 
string "string URI | 


publicDigitalCertificate CDATA #REOUIRED Public digital certificate 


trustedRoot CDATA #IMPLIED Name of the issuer of the certificate 


trustedRootURI CDATA #IMPLIED The URI of the issuer of the certificate for verification 
and valadation of the certificate. 


10 AdditionalAttributes 


PDX was engineered with the understanding that it is unrealistic to expect a standard to meet every 
organization’s needs, especially as those needs change with time. For that reason, the AdditionalAttributes 
and AdditionalAttribute elements are included in the standard to allow user-defined extensions to any 
Product Data eXchange entity. The AdditionalAttribute element defines a single new attribute; 
AdditionalAttributes enables the grouping of these new attributes. 


Note that the use of these elements in effect creates a custom version of the standard, and 
extensions defined in this manner will not interoperate with standard Product Data eXchange 
implementations. For this reason, users are encouraged to use expansion mechanisms judiciously, and 
to recommend any desired additions to the IPC Product Data eXchange committee. 


Item characteristics such as package, resistance, etc. attributes are not to be handled by 
AdditionalAttributes, but are to be handled by the characteristics element defined in IPC 2578. 
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All entities may have zero or more child AdditionalAttribute elements. The AdditionalAttributes element is a 
collection of AdditionalAttribute elements. 


«groupLabel, 
string 


+ AdditionalAttributes | (yy AdditionalAttribute | 


groupLabel CDATA #REOUIRED Label for a group of grouped additional attributes 


10.1 AdditionalAttribute 
Each AdditionalAttribute element represents a non-standard, user-defined attribute. 


«name, «value,  /3|-dimension, — (3): dataType, 
« AdditionalAttribute | string string "string string 
>) description, 
"string 


dataType (String | #IMPLIED The data type of the value 
Boolean | 
Float | 
Double | 
Decimal | 
DateTime | 
Binary | 
UriReference | 
Other ) 


dataTypeOther #IMPLIED If the above dataTypeCode attribute is set to "Other", use this 
attribute to provide a more descriptive value. If the above 
dataTypeCode is NOT set to "Other", LEAVE THIS FIELD 
BLANK. 


description CDATA #IMPLIED Description of the attribute 
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11 Alternateldentifiers 


+ Alternateldentifier _ 


SC 
— 


bedeite 


The Alternateldentifiers element holds a collection of Alternateldentifier elements that provide an optional, 
alternative mechanism for referring to an item or part. 


11.1 Alternateldentifier 


b Alternateldentifier | > alternateldentifierNum ber, > («description 
"string "string | 


4 


The Alternateldentifier element allows for the modeling of an item that maps to more than one part number 
(itemldentifier). This is necessary for supporting businesses, who through acguisitions or industry 
reguirements, have identical items represented by more than one part number (itemldentifier). A 
description is used to support classification of the alternate identifying number. 


alternateldentifierNumber CDATA #REOUIRED The identifying number. 


description CDATA #REOUIRED The description of the numbering scheme from which 
the alternateldentifierNumber is derived. 
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12 Document Type Definition (DTD) 


This specification uses a DTD instead of XML Schemas because, at the time of this writing, the XML 
Schema specification was not completely defined. It is expected that a future version of Product Data 
eXchange XML definitions will be written in XML Schema. 


The following is a master DTD that includes all elements from the IPC-2571, IPC-2576 and IPC-2578. 
<?xml version="1.0' encoding='UTF-8' ?> 
<!ELEMENT AdditionalAttribute EMPTY> 


<!ATTLIST AdditionalAttribute name CDATA #REQUIRED 
value CDATA #REQUIRED 
dimension CDATA #IMPLIED 
dataType (String | 
Boolean | 
Float | 
Double | 
Decimal | 
DateTime | 
Binary | 
UriReference | 
Other ) #IMPLIED 
dataTypeOther CDATA #IMPLIED 
description CDATA #IMPLIED > 
<IELEMENT AdditionalAttributes (AdditionalAttribute+)> 


<IATTLIST AdditionalAttributes groupLabel CDATA #REOUIRED > 
<IELEMENT Affectedltems (Affectedltem+)> 


<!ELEMENT Affectedltem (AdditionalAttributes* , BillOfMaterialMarkups? , ApprovedManufacturerListMarkups? , AttachmentMarkups?)> 


<!ATTLIST Affectedltem itemldentifier CDATA #REOUIRED 

itemUnigueldentifier IDREF #IMPLIED 
manufacturingSite CDATA #IMPLIED 
oldRevision CDATA #IMPLIED 
newRevision CDATA #REQUIRED 
obsoleteDate CDATA #REQUIRED 
effectiveDate CDATA #REQUIRED 
disposition CDATA #IMPLIED 
globalLifeCyclePhaseCode (Design | 

Preliminary | 

Prototype | 

Pilot | 

Conditional | 

Production | 

Pending | 

Inactive | 

Unqualified | 

Disqualified | 

Obsolete | 


Other ) #IMPLIED 
globalLifeCyclePhaseCodeOther CDATA #IMPLIED 
description CDATA #IMPLIED > 

<!ELEMENT Alternateltems (Alternateltem+)> 


<!ELEMENT Alternateltem (AdditionalAttributes*)> 

<!ATTLIST Alternateltem itemldentifier CDATA #IMPLIED 
itemUnigueldentifier IDREF #REQUIRED 
globalPreferredStatusCode CDATA #IMPLIED > 

<!ELEMENT ApprovedManufacturerListltem (AdditionalAttributes* , Alternateldentifiers?)> 


<!ATTLIST ApprovedManufacturerListltem manufacturerPartldentifier CDATA #REQUIRED 
manufacturerPartUniqueldentifier IDREF #IMPLIED 
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manufacturerContactUnigueldentifier IDREF #IMPLIED 
globalManufacturerPartStatusCode (Approved | 

QualityHold | 

UnderQualification | 

Unqualified | 

Disqualified | 

Obsolete | 

Nonpreferred | 

Conditional | 

Reference | 

Other ) #IMPLIED 
globalManufacturerPartStatusCodeOther CDATA #IMPLIED 


globalPreferredStatusCode CDATA #IMPLIED 
description CDATA #IMPLIED 
manufacturedBy CDATA #IMPLIED > 


<!ELEMENT ApprovedManufacturerListMarkups (ApprovedManufacturerListMarkup+)> 


<!ELEMENT ApprovedManufacturerListMarkup (ApprovedManufacturerListMarkupRowOld? , 
ApprovedManufacturerListMarkupRowNew?)> 


<!ATTLIST ApprovedManufacturerListMarkup globalMarkupTypeCode (Add | 

Modify | 

Delete | 

NoChange ) #REQUIRED > 
<!ELEMENT ApprovedManufacturerList (ApprovedManufacturerListltem+)> 
<!ELEMENT ApprovedManufacturerListMarkupRowNew (ApprovedManufacturerListltem)> 
<!ELEMENT ApprovedManufacturerListMarkupRowOld (ApprovedManufacturerListltem)> 
<IELEMENT Attachments (Attachment+)> 


<!ELEMENT Attachment (AdditionalAttributes*)> 


<!ATTLIST Attachment referenceName CDATA #IMPLIED 
universalResourceldentifier CDATA #REQUIRED 
fileldentifier CDATA #IMPLIED 
versionldentifer CDATA #IMPLIED 
fileSize CDATA #IMPLIED 
checkSum CDATA #IMPLIED 
isFileln (Yes | No ) #IMPLIED 
description CDATA #IMPLIED 


globalMimeTypeQualifierCode CDATA #IMPLIED 
attachmentModificationDate CDATA #IMPLIED > 
<IELEMENT AttachmentMarkups (AttachmentMarkup+)> 


<!ELEMENT AttachmentMarkup (AttachmentMarkupRowOld? , AttachmentMarkupRowNew?)> 


<IATTLIST AttachmentMarkup globalMarkupTypeCode (Add | Modify | Delete | NoChange ) #REOUIRED > 
<IELEMENT AttachmentMarkupRowNew (Attachment)> 


<!ELEMENT AttachmentMarkupRowOld (Attachment)> 
<!ELEMENT ApprovedSupplierList (ApprovedSupplierListltem+)> 
<!ELEMENT ApprovedSupplierListltem (AdditionalAttributes* , Alternateldentifiers?)> 


<!ATTLIST ApprovedSupplierListltem supplierPartldentifier CDATA #REOUIRED 
supplierPartUniqueldentifier ID #IMPLIED 
supplierPartContactUniqueldentifier IDREF #IMPLIED 
globalSupplierPartStatusCode CDATA #IMPLIED 
comments CDATA #IMPLIED 
suppliedBy CDATA #IMPLIED > 

<!ELEMENT BillOfMaterial (BillOfMaterialltem+)> 


<!ELEMENT BillOfMaterialltem (AdditionalAttributes* , ReferenceDesignators? , Alternateltems? , SerialNumbers?)> 
<!ATTLIST BillOfMaterialltem revisionldentifier CDATA #IMPLIED 


isSerializationRequired (Yes | No ) #IMPLIED 
globalBillOfMaterialTypeCode (DirectMaterial | 
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IndirectMaterial | 

Subassembly | 

PhantomSubassembly | 

EndProduct | 

Kit | 

Setup | 

AsNeeded | 

Reference | 

Nontangible | 

Other ) #IMPLIED 
globalBillOfMaterialTypeCodeOther CDATA #IMPLIED 
notes CDATA #IMPLIED 
billOfMaterialltemldentifier CDATA #IMPLIED 
billOfMaterialltemUniqueldentifier IDREF #IMPLIED 


itemOuantity CDATA #IMPLIED 
globalProductOuantityTypeCode (PerAssembly | 
PerSetup | 
AsNeeded | 
Shrinkage | 


Other) #IMPLIED 
globalProductQuantityTypeCodeOther CDATA #IMPLIED 
description CDATA #IMPLIED 
proprietarySequenceldentifier CDATA #IMPLIED > 

<!ELEMENT BillOfMaterialMarkups (BillOfMaterialMarkup+)> 


<!ELEMENT BillOfMaterialMarkup (BillOfMaterialMarkupRowOld? , BillOfMaterialMarkupRowNew?)> 


<!ATTLIST BillOfMaterialMarkup globalMarkupTypeCode (Add | 
Modify | 
Delete | 
NoChange ) #REQUIRED > 
<!ELEMENT BillOfMaterialMarkupRowNew (BillOfMaterialltem)> 


<!ELEMENT BillOfMaterialMarkupRowOld (BillOfMaterialltem)> 
<!ELEMENT Changes (Change+)> 
<!ELEMENT Change (AdditionalAttributes* , History? , Attachments? , Approvers? , Affecteditems?)> 


<!ATTLIST Change changeNumber CDATA #REQUIRED 

revisionIdentifier CDATA #IMPLIED 
changeOriginatedByName CDATA #IMPLIED 
changeOriginatedByContactUniqueldentifier IDREF #IMPLIED 
globalEngineeringChangeStatusCode (Issueldentified | 

ChangeRequested | 

Underlnvestigation | 

ChangeOrderProposed | 

ApprovalPending | 

OnHold | 

Approved | 

Cancelled | 

Rejected | 

Completed | 

Released | 

Implemented | 

Other) #IMPLIED 
globalEngineeringChangeStatusCodeOther CDATA #IMPLIED 


changeStatusDate CDATA #IMPLIED 
changeType CDATA #IMPLIED 
changeSubType CDATA #IMPLIED 
changeOriginationDate CDATA #IMPLIED 
requestReason CDATA #IMPLIED 
changeReason CDATA #IMPLIED 
workflow CDATA #IMPLIED 
changeRequestDescription CDATA #IMPLIED 
changeOwnerName CDATA #IMPLIED 
changeOwnerContactUnigueldentifier IDREF #IMPLIED 
description CDATA #IMPLIED > 


<!ELEMENT ChangeHistory (ChangeHistoryltem+)> 
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<!ELEMENT ChangeHistoryltem (AdditionalAttributes*)> 


<!ATTLIST ChangeHistoryltem changeNumber CDATA #REQUIRED 

revisionIdentifier CDATA #IMPLIED 
globalLifeCyclePhaseCode (Design | 

Preliminary | 

Prototype | 

Pilot | 

Conditional | 

Production | 

Pending | 

Inactive | 

Unqualified | 

Disqualified | 

Obsolete | 

Other) #IMPLIED 
globalLifeCyclePhaseCodeOther CDATA #IMPLIED 
releasedDate CDATA #IMPLIED 
incorporatedDate CDATA #IMPLIED 
effectiveDate CDATA #IMPLIED 
obsoleteDate CDATA #IMPLIED 
changeType CDATA #IMPLIED 
proposedRevision CDATA #IMPLIED 
globalEngineeringChangeStatusCode (Issueldentified | 

ChangeRequested | 

Underlnvestigation | 

ChangeOrderProposed | 

ApprovalPending | 

OnHold | 

Approved | 

Rejected | 

Completed | 

Released | 

Implemented | 

Other) #IMPLIED 
globalEngineeringChangeStatusCodeOther CDATA #IMPLIED 
description CDATA #IMPLIED > 

<!ELEMENT Characteristics (MeasuredCharacteristic* , RangedCharacteristic* , EnumeratedCharacteristic* , TextualCharacteristic*)> 


<!ATTLIST Characteristics category CDATA #REQUIRED > 
<!ELEMENT MeasuredCharacteristic EMPTY> 


<!ATTLIST MeasuredCharacteristic definitionSource CDATA #IMPLIED 
measuredCharacteristicName CDATA #IMPLIED 
measuredCharacteristicValue CDATA #IMPLIED 
engineeringUnitOfMeasure CDATA #IMPLIED 
engineeringNegativeTolerance CDATA #IMPLIED 
engineeringPositiveTolerance CDATA #IMPLIED > 
<!ELEMENT RangedCharacteristic EMPTY> 


<!ATTLIST RangedCharacteristic definitionSource CDATA #IMPLIED 
rangedCharacteristicName CDATA #IMPLIED 
rangedCharacteristicLowerValue CDATA #IMPLIED 
rangedCharacteristicUpperValue CDATA #IMPLIED 
engineeringUnitOfMeasure CDATA #IMPLIED 
engineeringNegativeTolerance CDATA #IMPLIED 
engineeringPositiveTolerance CDATA #IMPLIED > 

<!ELEMENT EnumeratedCharacteristic EMPTY> 


<!ATTLIST EnumeratedCharacteristic definitionSource CDATA #IMPLIED 
enumeratedCharacteristicName CDATA #IMPLIED 
enumeratedCharacteristicValue CDATA #IMPLIED > 
<!ELEMENT TextualCharacteristic EMPTY> 


<!ATTLIST TextualCharacteristic definitionSource CDATA #IMPLIED 
textualCharacteristicName CDATA #IMPLIED 
textualCharacteristicValue CDATA #IMPLIED > 
<!ELEMENT Contacts (Contact+)> 


<!ELEMENT Contact (AdditionalAttributes* , History? , Attachments? , ContactRoles* , PublicDigitalCertificate*)> 
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<IATTLIST Contact contactldentifier CDATA #REOUIRED 


contactUnigueldentifier 
contactName 
addressLine1 
addressLine2 
addressLine3 
cityName 

regionName 
globalCountryCode 
nationalPostalCode 
telephoneNumber 
facsimileNumber 
department 
businessName 
globalBusinessldentifier 
emailAddress 


ID #REQUIRED 
CDATA #REQUIRED 
CDATA #IMPLIED 
CDATA #IMPLIED 
CDATA #IMPLIED 

CDATA #IMPLIED 
CDATA #IMPLIED 

CDATA #IMPLIED 

CDATA #IMPLIED 

CDATA #IMPLIED 

CDATA #IMPLIED 
CDATA #IMPLIED 
CDATA #IMPLIED 

CDATA #IMPLIED 

CDATA #IMPLIED 


universalResourceldentifier CDATA #IMPLIED 

contactStatus CDATA #IMPLIED 
isTopLevel (Yes | No) #IMPLIED 
globalPartnerClassificationCode (Carrier | 

Distributor | 

EndUser | 

EndUserGovernment | 

Financier | 

Manufacturer | 

Retailer | 

Shopper | 

FreightForwarder | 

Broker | 

CustomsBroker | 

Warehouser | 

DistributionCenter | 

ContractManufacturer | 

Reseller | 

OriginalEquipmentManufacturer | 

Other) #IMPLIED 
globalPartnerClassificationCodeOther CDATA #IMPLIED 
globalPartnerSubClassificationCode CDATA #IMPLIED 
globalLocationldentifier CDATA #IMPLIED 
postOfficeBoxldentifier CDATA #IMPLIED > 

<!ELEMENT History (Historyltem+)> 


<!ELEMENT Historyltem (AdditionalAttributes*)> 


<!ATTLIST Historyltem action 
revisionldentifier CDATA #IMPLIED 
userName CDATA #REOUIRED 
userContactUnigueldentifier IDREF #IMPLIED 
modificationDate CDATA #REQUIRED 
historyltemStatus CDATA #IMPLIED 
details CDATA #IMPLIED 
comments CDATA #IMPLIED > 

<!ELEMENT Items (Item+)> 


CDATA #REQUIRED 


<!ELEMENT Item (AdditionalAttributes* , BillOfMaterial? , ApprovedManufacturerList? , History? , Attachments? , ChangeHistory? , 
Characteristics? , Alternateltems? , SerialNumbers? , Alternateldentifiers?)> 


<!ATTLIST Item itemldentifier 

itemUniqueldentifier ID #REQUIRED 
globalLifeCyclePhaseCode (Design | 

Preliminary | 

Prototype | 

Pilot | 

Conditional | 

Production | 

Pending | 

Inactive | 

Unqualified | 

Disqualified | 


CDATA #REQUIRED 
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Obsolete | 
Other ) #IMPLIED 
globalLifeCyclePhaseCodeOther CDATA #IMPLIED 


globalProductTypeCode CDATA #IMPLIED 
itemClassification CDATA #IMPLIED 
revisionidentifier CDATA #IMPLIED 
versionldentifer CDATA #IMPLIED 
proprietaryProductFamily CDATA #IMPLIED 
category CDATA #IMPLIED 
globalProductUnitOfMeasureCode CDATA #IMPLIED 
makeBuy (Make | 

Buy | 

Consigned | 

VendorManaged | 

Subcontracted | 

Unspecified | 

Other) #IMPLIED 
makeBuyOther CDATA #IMPLIED 
minimumShippableRevision CDATA #IMPLIED 
revisionReleasedDate CDATA #IMPLIED 


revisionIncorporatedDate CDATA #IMPLIED 
isSerializationRequired (Yes | No) #IMPLIED 
isCertificationRequired (Yes | No) #IMPLIED 


ownerName CDATA #IMPLIED 
ownerContactUnigueldentifier IDREF #IMPLIED 
isTopLevel (Yes | No) #IMPLIED 
description CDATA #IMPLIED > 


<!ELEMENT ManufacturerParts (ManufacturerPart+)> 


<!ELEMENT ManufacturerPart (AdditionalAttributes* , ApprovedSupplierList? , History? , Attachments? , Alternateldentifiers?)> 


<!ATTLIST ManufacturerPart manufacturerPartldentifier CDATA #REQUIRED 
manufacturerPartUniqueldentifier ID #IMPLIED 
manufacturerName CDATA #REQUIRED 


manufacturerContactUniqueldentifier IDREF #IMPLIED 
globalManufacturerPartStatusCode (Approved | 

QualityHold | 

UnderQualification | 

Unqualified | 

Disqualified | 

Obsolete | 

Nonpreferred | 

Conditional | 

Reference | 

Other ) #IMPLIED 
globalManufacturerPartStatusCodeOther CDATA #IMPLIED 


referenceNotes CDATA #IMPLIED 
manufacturerPartType CDATA #IMPLIED 
description CDATA #IMPLIED 
owner CDATA #IMPLIED 
ownerContactUniqueldentifier IDREF #IMPLIED 
isTopLevel (Yes | No ) #IMPLIED > 


<!ELEMENT ProductDataeXchangePackage (AdditionalAttributes* , Items? , Changes? , ManufacturerParts? , SupplierParts? , History? , 
Attachments? , Contacts? , AsBuiltProduct*)> 


<IATTLIST ProductDataeXchangePackage thisDocumentldentifier CDATA #REOUIRED 
thisDocumentGenerationDateTime CDATA #REQUIRED 
thisDocumentModificationDateTime CDATA #REQUIRED 


originatedByContactName CDATA #IMPLIED 
originatedByContactUnigueldentifier IDREF #IMPLIED 
packageType CDATA #IMPLIED 
description CDATA #IMPLIED 
dataSource CDATA #IMPLIED 
thisDocumentCopyright CDATA #IMPLIED > 


<!ELEMENT ReferenceDesignators (ReferenceDesignator+)> 
<!ELEMENT ReferenceDesignator EMPTY> 


<!ATTLIST ReferenceDesignator referenceDesignatorName CDATA #REQUIRED > 
<!ELEMENT SerialNumbers (SerialNumberRange* , SerialNumberldentification*)> 
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<!ELEMENT SerialNumberRange EMPTY> 


<!ATTLIST SerialNumberRange firstSerialNumber CDATA #REQUIRED 
lastSerialNumber CDATA #IMPLIED 
increment CDATA #IMPLIED 
sequenceNumber CDATA #IMPLIED > 

<!ELEMENT Approvers (Approver+)> 


<!ELEMENT Approver (AdditionalAttributes*)> 


<!ATTLIST Approver globalEngineeringChangeResponseCode (Approve | 
Reject | 
Waive | 
ApproveWithConditions | 
ForwardToAnotherParty | 
Other) #IMPLIED 
globalEngineeringChangeResponseCodeOther CDATA #IMPLIED 


comments CDATA #IMPLIED 
workflow CDATA #IMPLIED 
globalApproverTypeCode (Required | 

Optional | 

Informational | 

Other) #REQUIRED 
globalApproverTypeCodeOther CDATA #IMPLIED 
approverName CDATA #REQUIRED 
approverContactUniqueldentifier IDREF #IMPLIED 
alternateApproverContactUniqueldentifier IDREF #IMPLIED 
approvedDate CDATA #IMPLIED 
approverWorkflowStatus CDATA #IMPLIED 
alternateApproverName CDATA #IMPLIED > 


<!ELEMENT SupplierParts (SupplierPart+)> 


<!ELEMENT SupplierPart (AdditionalAttributes* , History? , Attachments?)> 


<!ATTLIST SupplierPart supplierPartldentifier CDATA #REQUIRED 
supplierPartUniqueldentifier ID #IMPLIED 
supplierName CDATA #REQUIRED 


supplierContactUniqueldentifier IDREF #IMPLIED 
globalSupplierPartStatusCode CDATA #IMPLIED 


referenceNotes CDATA #IMPLIED 
supplierPartType CDATA #IMPLIED 
ownerName CDATA #IMPLIED 
ownerContactUniqueldentifier IDREF #IMPLIED 
isTopLevel (Yes | No) #IMPLIED 
description CDATA #IMPLIED 


olobalReturnProductinstructionCode CDATA #IMPLIED > 
<!-- Elements for IPC-2576 --> 
<IELEMENT AsBuiltProduct (Productinstance* , AdditionalAttributes*)> 


<IATTLIST AsBuiltProduct globalProductldentifier CDATA #REOUIRED 
asBuiltProductQuantity CDATA #REQUIRED 
manufacturerUnitOfMeasure CDATA #IMPLIED 
customerProductNumber CDATA #IMPLIED 
customerldentifier CDATA #IMPLIED 
primaryldentifier CDATA #IMPLIED 
secondaryldentifier CDATA #IMPLIED 
isTopLevel (Yes | No ) #IMPLIED > 
<!ELEMENT Productlnstance (AdditionalAttributes* , Configuration“ , Lot“ , WorkOrder* , Packaging“ , Process*)> 


<!ATTLIST Productinstance itemldentifier CDATA #REQUIRED 
itemUniqueldentifier IDREF #IMPLIED 
proprietaryProductFamily CDATA #IMPLIED 
globalBusinessldentifier CDATA #IMPLIED 
globalProductldentifier CDATA #IMPLIED 


traceabilityType CDATA #IMPLIED 
manufacturerName CDATA #IMPLIED 
productRevision CDATA #IMPLIED 
productVersion CDATA #IMPLIED 
buildDate CDATA #REQUIRED 
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materialldentifier CDATA #REOUIRED 
forecastProductldentifer CDATA #IMPLIED 
purchaseOrder CDATA #IMPLIED 


purchaseOrderLineltem CDATA #IMPLIED 
authorizationLineltem CDATA #IMPLIED 


customerSerial CDATA #IMPLIED 
customerPart CDATA #IMPLIED 
customerRevision CDATA #IMPLIED 
sequenceNumber CDATA #IMPLIED 
manufacturingPartStatus CDATA #IMPLIED 
customerVersion CDATA #IMPLIED 


globalLocationldentifier CDATA #IMPLIED 

globalCountryCode CDATA #IMPLIED 

description CDATA #IMPLIED 

proprietarySerialldentifier CDATA #IMPLIED > 
<IELEMENT Configuration EMPTY> 


<IATTLIST Configuration configurationType CDATA #REOUIRED 
configurationData CDATA #REOUIRED > 
<IELEMENT Lot EMPTY> 


<IATTLIST Lot lotNumber CDATA #REOUIRED 
lotOuantity CDATA #IMPLIED 
manufacturerUnitOfMeasure CDATA #IMPLIED 
globalBusinessldentifier CDATA #IMPLIED 
globalCountryCode CDATA #IMPLIED globalProductldentifier CDATA #IMPLIED 
referenceDesignator CDATA #IMPLIED 
lotType CDATA #REQUIRED > 
<!ELEMENT WorkOrder EMPTY> 


<!ATTLIST WorkOrder manufacturingWorkOrderType CDATA #REQUIRED 
manufacturingWorkOrderNumber CDATA #REQUIRED > 
<!ELEMENT Packaging EMPTY> 


<!ATTLIST Packaging packagingUniqueldentifier CDATA #REQUIRED 
cartonldentifier CDATA #IMPLIED 
palletidentifier CDATA #IMPLIED > 

<!ELEMENT Process EMPTY> 


<!ATTLIST Process stepldentifier CDATA #REQUIRED 
processDateTime CDATA #IMPLIED 
operation CDATA #IMPLIED 
resource CDATA #IMPLIED 
router CDATA #IMPLIED > 
<!ELEMENT Alternateldentifier EMPTY> 


<!ATTLIST Alternateldentifier alternateldentifierNumber CDATA #IMPLIED 
description CDATA #IMPLIED > 
<!ELEMENT Alternateldentifiers (Alternateldentifier+)> 


<!ELEMENT ContactRoles (ContactRole*)> 


<!ATTLIST ContactRoles groupLabel CDATA #REQUIRED > 
<!ELEMENT ContactRole (GroupRole*)> 


<!ATTLIST ContactRole groupRoleDescription CDATA #IMPLIED > 
<!ELEMENT Role (#PCDATA)> 


<IELEMENT GroupRole EMPTY> 


<IATTLIST GroupRole role CDATA #REOUIRED 
isAlternate (Yes | No) #REOUIRED 
description CDATA #IMPLIED > 

<IELEMENT PublicDigitalCertificate EMPTY> 


<!ATTLIST PublicDigitalCertificate publicDigitalCertificate CDATA #REOUIRED 
trustedRoot CDATA #IMPLIED 
trustedRootURI CDATA #IMPLIED > 

<!ELEMENT SerialNumberldentification EMPTY> 
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<IATTLIST SerialNumberldentification seguenceNumber CDATA #IMPLIED 
ProprietarySerialldentifier CDATA #IMPLIED > 
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Appendix A — IPC Web-based Standards (IPC25XX) 


The web-based standards (IPC 25XX) are designed to foster application integration and electronic 
commerce through data and information interchange standards based on XML. There is no need for a 
common object model, programming language, network protocol, persistent storage mechanism or 
operating system for two applications to exchange XML messages formatted using the web-based 
standards. The two applications simply need to be able to format, transmit, receive and consume a 
standardized XML message. 


A web-based standards series has been identified for each of the value-added activities occurring 
throughout the product life cycle of an electronics product. The web-based standards are: 

IPC-2500 — Framework Standard 

IPC-2510 — Product Data Representation 

IPC-2520 — Product Data Ouality 

IPC-2530 — Surface Mount Eguipment Standard Recipe File Format 

IPC-2540 — Shop Floor Eguipment Communications 

IPC-2550 — Manufacturing Execution Systems Communications 

IPC-2560 — Enterprise Resource Planning Systems Communications 

IPC-2570 — Supply Chain Communications 


Table A-1 shows the correlation of the different standards in each of the series. Although not every 
standard has been started, the figure represents a coordinated opportunity to maintain consistency 
throughout the standard development cycle. 


Table A-1 CADICAM Standardization 


IPC Number/ -xxx1 -XXX2 -XXX3 -XXX4 -XXX5 -XXX6 -XXX7 -XXX8 -XXX9 

Function Generic Administ Documnt | Board Bare Bd | Assy Assy/ Comp. & | Informa. 
Fabricat Test Manufac Test/ Material Modeling 

Insp. 

IPC-2500  CAMX | IPC-2501 

Framework PINS 

IPC-2510 IPC- IPC- IPC- IPC- IPC- IPC- IPC- | PC- IPC- 

GenCAM 2511A 2512A 2513A 2514A 2515A 2516A 2517A 2518A 2519A 

Product Data (Pub) (Pub) (Pub) (Pub) (Pub) (Pub) (Pub) (Pub) (Pub) 

IPC-2520 IPC-2524 

Quality (Pub) 

Product Data 

IPC-2530 SRFF IPC-2531 

Process Data ANSI 

Recipe file Draft 

IPC-2540 Shop | IPC-2541 IPC-2546 | IPC-2547 

Floor (Pub) (Pub) 274 |F 

Communicate 

1PC-2550 IPC-2551 IPC-2554 IPC-2556 

Execution PINS Working PINS 

Communicate draft 

IPC-2560 

Enterprise 

Communicate 

IPC-2570 Supply IPC-2576 | IPC-2577 | IPC-2578 

Chain (Pub) Proposal (Pub) 

Communicate 


